Enable publication at crates.io #98
Conversation
This will enable crates.io publication once thvdveld/cc2538-hal#2 is published (and the cc2538-hal dependency line updated).
|
This would be absolutely great but I am afraid there are several showstoppers ATM. Some comments:
|
Contributes-To: openwsn-berkeley#98
Contributes-To: openwsn-berkeley#98
|
Hm ... it's certainly inconvenient when optional dependencies are not published, as crates.io doesn't allow them to be second-class. A workflow I've been using in riot-wrappers a lot was to have a release mode where I'd commit a change that comments out all the optional stuff that's not published yet, then bump the version, publish, and revert the commenting-out commit right away. It's not pretty, but it works as soon as there is one back-end that is published. (And if it's not cc2538, I figure that Rust software implementations of crypto would sooner or later be on the menu, as they'd enable using this efficiently on x86 and WASM). On the long run, is there a plan for how the backends could become decoupled? A model that has worked well for libOSCORE, albeit on the C side but with a very Rust mindset, was that the published library just depends on the platform to provide an implementation of the backend interface, and then some back-ends could be available via crates.io, while others wait for upstreams to be publishable. |
|
Just leaving a thought here, me and @malishav discussed over lunch today and we see the following possible paths to enable publication at crates.io:
|
|
Is the #103 approach not viable? That would allow easily keeping backends around that are not fully on crates (PSA is surely nice to have). |
|
On Sun, Oct 08, 2023 at 04:00:06AM -0700, Mališa Vučinić wrote:
I am missing how #103 enables publication. Won't we still need a
patched dependency to these crates (hacspec, PSA)?
If 103 is complete, the library crate itself won't have a dependency on
any crypto implementation any more -- only applications will pull in
that dependency. edhoc-rs will only depend on edhoc-consts and
edhoc-crypto-trait (and the various -ead- crates, but I'd suggest doing
the same game there).
Then the only dependency lib would have would be a dev dependency that's
needed for the tests (on a remaining edhoc-crypto or directly on the
selected edhoc-crypto-*), and that could either be commented out for
releases (admittedly gaining little in complexity) or preferably moved
into a tests crate, together with whatever is the entry point for hax.
|
|
This will need a complete redo with the latest main branch, but after #139, all dependencies should be shippable. We may want to not hurry this, because I think that a few refactorings might bring the number of published crates down (so by not going to crates.io right away we avoid having some linger forever in 0.4): if we follow up on the hackathon plan based on Marco's designs, I think we won't need the 3 EAD crates in the dependency tree any more, and the consts can go into the main library. |
|
Closing as obsolete with the publications around 0.4.0. |
For exploring this crate, it would be helpful if it were uploaded to crates.io.
I've started adding a few version numbers in dependencies to make that work, but there are some showstoppers along the way which I'd like to track here:
This PR should contain valid changes with our without fixes to the above; once all of those are in, I'd appreciate if the maintainers would consider publication, as it helps with visibility and makes the documentation accessible more easily. (It'd also help dependent projects in their own publication, but I'm not at the point yet where I have something there).